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INTRODUCTION 


Over  the  last  several  years,  mobile  devices  have  become  increasingly  capable  and 
ubiquitous.  The  term  mobile  device  in  the  context  of  this  work  includes  cell  phones, 
smart  phones,  and  network-enabled  Personal  Digital  Assistants  (PDAs).  The  popularity 
of  these  devices  has  led  to  some  striking  numbers  in  terms  of  market  penetration. 
According  to  research  firm  Informa  [1],  in  November  2007,  worldwide  mobile  phone 
subscriptions  reached  3.3  billion  -  equivalent  to  half  the  global  population.  Of  course 
this  number  is  an  aggregate  value  for  all  the  world’s  nations.  Some  countries  have  higher 
penetration  rates  than  others.  Eurostat,  an  organization  that  tracks  statistics  for  European 
Commission  nations,  reported  that  there  are  nearly  95  mobile  phones  for  every  100 
Europeans  [2],  Penetration  is  as  high  as  158%  in  Lithuania  [2]  meaning  some  people 
own  multiple  devices. 

In  addition  to  being  extremely  popular,  mobile  devices  are  more  powerful  than 
ever.  The  processing  power  of  today’s  mobile  devices  is  greater  than  that  of  the  desktop 
PCs  used  in  the  1990s  [3].  The  content  capture  and  communication  capabilities  of 
modem  mobile  devices  have  opened  the  door  for  a  wide  variety  of  new  services.  In 
addition  to  voice,  text,  and  e-mail  services  that  have  always  been  popular,  it  is  now 
possible  for  mobile  devices  to  support  streaming  multimedia  and  video  conferencing. 
Large  companies,  like  Microsoft  and  Intel,  have  recognized  the  value  of  the  growing 
mobile  technology  market  and  are  working  vigorously  to  capitalize  upon  the  demand. 
The  importance  of  mobile  technology  to  such  companies  was  seen  at  the  January  2008 
Consumer  Electronics  Show  where  Microsoft  chairman  Bill  Gates  remarked,  “The  trend 
now  is  to  have  information  wherever  you  want  [4].”  This  trend  echoes  the  needs  of  the 
military  as  well  as  first  responders  for  “the  right  information,  at  the  right  place,  at  the 
right  time  [5].” 

The  power  and  ubiquity  of  mobile  devices  does  not  come  without  a  cost, 
however.  The  use  of  mobile  devices  and  networks  comes  with  significant  privacy 
challenges.  This  thesis  explores  an  implementation  of  privacy  protection  for  mobile 
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networks  used  by  first  responders  via  network  virtualization.  Herein  network 
virtualization  is  defined  as  methods  used  to  create  a  logically  and/or  physically  separated 
set  of  resources  running  on  top  of  a  single  physical  network.  TwiddleNet,  a  wireless 
system  comprised  of  mobile  devices,  will  be  used  as  a  platform  for  proof-of-concept  and 
implementation. 

A.  DEFINITION  OF  PRIVACY 

Privacy  can  mean  many  things  depending  on  the  context  of  the  situation.  Calcutt 
broadly  defines  privacy  as  “the  right  of  the  individual  to  be  protected  against  intrusion 
into  his  personal  life  or  affairs  ...  by  direct  physical  means  or  by  publication  of 
information  [6].”  As  noted  in  [7],  privacy  can  be  broken  down  into  four  separate 
concepts:  information  privacy,  bodily  privacy,  privacy  of  communications,  and  territorial 
privacy.  Information  privacy  refers  to  controls  placed  on  the  collection  and  handling  of 
personal  data,  such  as  credit  information,  and  medical  and  government  records.  Bodily 
privacy  deals  with  the  protection  of  people’s  physical  selves  against  invasive  procedures, 
such  as  genetic  tests,  undue  drug  testing,  and  cavity  searches.  The  security  and  privacy 
of  mail,  telephones,  e-mail  and  other  forms  of  communication  is  covered  by  privacy  of 
communications.  Territorial  privacy  involves  the  setting  of  limits  on  intrusion  into  the 
domestic  and  other  environments  such  as  the  workplace  or  public  space. 

This  thesis  will  concentrate  on  information  privacy  and  privacy  of 
communications,  as  the  other  concepts  are  not  related  to  the  context  of  this  work.  From 
here  on  these  concepts  will  more  generally  be  referred  to  as  “content  privacy.” 

B.  PRIVACY  REQUIREMENTS  FOR  MOBILE  NETWORKS 

Users  of  mobile  networks  may  require  privacy  so  as  to  prevent  an  attacker  from 
learning  information,  such  as  where  they  live,  where  they  work,  whom  they  communicate 
with,  and  what  they  say.  These  privacy  issues  have  been  a  topic  of  a  great  deal  of  study. 
Privacy  requirements  most  often  identified  in  literature  include  content  privacy,  identity 
privacy,  location  privacy,  and  authentication. 
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Content  privacy  was  previously  defined  in  the  discussion  of  information  privacy 
and  privacy  of  communications.  At  the  most  basic  level,  content  privacy  can  be  thought 
of  as  confidentiality.  Users  require  that  their  information  is  not  accessible  to 
unauthorized  parties  either  during  transmission  across  the  network  or  when  stored  in  a 
record  system. 

Identity  privacy  deals  with  protecting  a  user’s  name  or  other  identifiers  that  could 
be  used  to  uniquely  identify  him  [8].  Users  may  want  to  communicate  anonymously  or 
pseudonymously  without  revealing  their  actual  identity.  They  may  want  to  reveal  their 
identity  only  to  the  other  communicating  party  while  remaining  anonymous  to  any 
intermediaries  or  eavesdroppers,  or  they  may  want  to  remain  anonymous  with  respect  to 
the  communication  network  itself  [8],  [9], 

Location  privacy  typically  refers  to  privacy  of  the  user’s  point  of  attachment  to 
the  network,  i.e.,  their  network  location  or  address.  The  aim  of  location  privacy  is  to 
prevent  an  attacker  or  observer  from  linking  the  two  locations  to  the  same  user  when  that 
user  changes  points  of  attachment  to  the  network  [10],  Privacy  of  geographic  location 
can  be  a  concern,  too,  as  it  is  possible  to  ascertain  the  rough  location  of  a  transmitter  by 
triangulation  or  signal  analysis;  however  protection  against  these  methods  is  beyond  the 
scope  of  this  work. 

Authentication  refers  to  a  process  by  which  a  user  verifies  that  a  communicating 
party  is  in  fact  who  they  claim  to  be.  This  is  required  to  prevent  an  adversary  from 
impersonating  a  legitimate  user  and  thereby  gaining  access  to  privileged  information. 
Ideally,  mutual  authentication  is  in  place,  where  a  user  authenticates  himself  to  the 
network  and  the  network  authenticates  itself  to  the  user. 

C.  PRIVACY  REQUIREMENTS  FOR  FIRST  RESPONDERS 

1.  General  Requirements 

First  responders  may  come  from  many  disparate  organizations  and  agencies.  It  is 
not  uncommon  to  have  individuals  from  fire,  police  or  other  law  enforcement,  medical, 

military,  federal,  state,  and  local  government  agencies,  as  well  as  non-government 

3 


agencies,  responding  to  an  event.  Members  from  all  these  groups  may  require  access  to 
the  mobile  network  in  order  to  do  their  jobs.  Each  group  may  have  different 
requirements  in  terms  of  the  level  of  privacy  needed.  Therefore,  as  a  general 
requirement,  each  group  of  first  responders  needs  to  be  able  to  keep  their  information 
separate  from  other  groups  as  the  situation  dictates.  A  group  also  should  be  able  to  share 
information  with  all  other  groups  if  desired. 

2.  Specific  Requirements 

a.  Medical  Information 

As  previously  mentioned,  TwiddleNet  will  be  the  platform  used  for 
implementation  of  this  thesis  work.  A  typical  use  case  scenario  for  TwiddleNet  involves 
emergency  medical  personnel  using  the  system  to  gather  triage  information  about  victims 
of  a  natural  disaster  or  other  mass  casualty  incident.  Medical  information  of  this  type  is 
subject  to  requirements  delineated  in  the  Health  Insurance  Portability  and  Accountability 
Act  (HIPAA)  [11],  which  establishes  standards  for  the  security  and  privacy  of  patient 
health  information.  HIPAA  restricts  the  use  and  disclosure  of  patient  health  information. 
Therefore,  it  is  desirable  to  restrict  the  access  to  this  information  to  medical  personnel 
only. 


b.  Privacy  A ct  Information 

Information  about  U.S.  citizens  or  permanent  residents  collected  by  first 
responders  working  for  the  Department  of  Defense  (DoD)  or  other  federal  government 
agencies  is  subject  to  the  provisions  of  the  Privacy  Act  of  1974  [12].  Such  information 
includes  education  and  medical  information,  financial  transactions,  criminal  or 
employment  history,  and  any  identifiers  assigned  to  an  individual  such  as  a  Social 
Security  Number  [13].  The  purpose  of  the  Privacy  Act  is  to  regulate  the  collection, 
maintenance,  use,  and  dissemination  of  personal  information  by  federal  agencies.  In 
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keeping  with  this  purpose,  any  personal  information  collected  by  first  responders  covered 
by  the  act  should  be  handled  in  such  a  way  as  to  prevent  inadvertent  disclosure  to  persons 
without  a  need  to  know. 

c.  Military  Information 

First  responder  teams  often  include  military  personnel.  Military  members 
typically  will  have  requirements  for  private  communication  of  sensitive  information,  such 
as  that  pertaining  to  force  protection.  In  this  case,  it  is  desirable  to  restrict  the  access  of 
this  information  to  military  and  perhaps  law  enforcement  personnel. 

D.  THREAT  TO  PRIVACY  IN  MOBILE  NETWORKS 

This  work  will  consider  two  general  categories  of  threats  to  privacy  in  mobile 
networks:  eavesdropping  and  surveillance,  and  the  threat  posed  by  the  use  of  unique 
identifiers. 

1.  Eavesdropping  and  Surveillance 

Wireless  networks  are  inherently  insecure  due  to  the  nature  of  the  medium.  In  a 
wireless  shared  medium,  assuming  all  stations  are  using  the  same  protocols,  any  station 
can  receive  all  traffic  from  other  stations  that  are  within  range  and  can  transmit  to  any 
station  within  range.  Thus,  any  traffic  that  is  sent  unencrypted  can  be  easily  intercepted. 
This  represents  a  threat  not  only  to  the  content  privacy  of  a  user’s  communications,  but 
also  to  identity  and  location  privacy,  as  intercepted  traffic  may  be  analyzed  to  ascertain 
certain  unique  identifiers  (discussed  in  the  next  section)  that  can  lead  to  a  compromise  in 
privacy. 

Two  types  of  parties  may  be  seen  as  posing  a  threat  by  eavesdropping  or 

observation:  casual  observers  and  attackers.  A  casual  observer  herein  is  defined  as 

another  user  of  the  mobile  network  who  may  have  access  to,  or  receive  information  sent 
by  a  user,  but  did  not  actively  seek  out  that  information.  For  example,  in  the  current 
TwiddleNet  implementation  all  active  users  of  the  system  receive  notification  of  new 
content  that  a  user  has  made  available  regardless  of  the  user’s  desire  for  privacy  control. 
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Addressing  this  threat  is  the  primary  focus  of  this  work.  The  implementation  work  done 
for  this  thesis  allows  TwiddleNet  users  to  have  more  control  over  the  recipients  of  their 
notifications.  For  instance,  if  a  medical  responder  wishes  only  to  alert  other  medical 
users,  due  to  concerns  over  patient  privacy,  he  can  do  so,  preventing  other  users,  such  as 
fire  or  police  responders,  from  having  access  to  the  information. 

The  second  party  seen  as  posing  a  threat  via  eavesdropping  is  an  attacker.  An 
attacker  is  considered  to  be  an  individual  who  actively  seeks  out  information  that  he 
would  not  otherwise  have  access  to.  For  instance  an  attacker  may  use  a  “packet  sniffer” 
or  protocol  analyzer  to  glean  information  from  the  wireless  medium.  This  threat  is 
normally  addressed  through  the  use  of  encryption  and  authentication.  In  Wireless  Local 
Area  Networks  (WLANs)  based  on  the  IEEE  802.11  standard,  three  cryptographic 
protocols  are  commonly  used:  Wired  Equivalent  Privacy  (WEP),  the  Temporal  Key 
Integrity  Protocol  (TKIP),  and  the  Counter  Mode  with  Cipher  Block  Chaining  Message 
Authentication  Code  Protocol  (CCMP)  [14].  WEP  and  TKIP  are  based  on  the  Rivest 
Cipher  4  (RC4)  algorithm,  and  CCMP  is  based  on  the  Advanced  Encryption  Standard 
(AES).  In  Wireless  Wide  Area  Networks  (WWANs),  like  the  Global  System  for  Mobile 
Communications  (GSM)  cellular  networks,  the  encryption  algorithms  used  are  dependent 
on  the  particular  service  provider  [15]. 

It  should  be  noted  that  there  is  a  great  deal  of  concern  among  privacy  groups 
surrounding  the  threat  posed  by  surveillance  of  mobile  networks  (indeed  any  electronic 
communications)  on  the  part  of  law  enforcement  and  intelligence  agencies  [16],  [17]. 
This  is  not  considered  as  a  threat  in  this  work,  as  law  enforcement  agencies,  after 
obtaining  a  warrant,  are  authorized  to  conduct  such  surveillance  and  compliance  by 
network  operators  with  this  type  of  surveillance  is  required  by  law  [18],  [19],  [20],  [21]. 

2.  Unique  Identifiers 

As  mentioned  above,  encryption  is  commonly  employed  to  ensure  content  privacy 
in  mobile  networks.  A  user’s  privacy  may  still  be  at  risk  however,  due  to  unique 
identifiers  used  in  network  protocols  that  may  lead  to  a  compromise  in  identity  or 
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location  privacy.  Even  with  encryption  in  place  such  identifiers  may  reveal  the  user’s 
identity  and  activities  to  anyone  within  transmission  range. 

An  overview  of  some  protection  mechanisms  aimed  at  addressing  this  threat  is 
presented  in  Chapter  II.  Implementation  of  protection  measures  for  unique  identifiers  is 
beyond  the  scope  of  this  work  however. 

E.  OBJECTIVE 

The  objective  of  this  thesis  is  to  implement  privacy  measures  in  mobile  networks 
for  first  responders  using  network  virtualization.  The  following  research  questions  will 
be  addressed:  1)  Is  network  virtualization  an  appropriate  choice  for  implementing 
privacy  protections?  2)  How  well  does  the  implementation  address  the  stated  privacy 
requirements? 

F.  SCOPE 

The  scope  of  this  thesis  is  limited  to  providing  content  privacy  protection  for 
mobile  networks.  TwiddleNet  will  be  used  as  the  platform  for  implementation.  The 
scope  of  work  is  limited  to  those  changes  to  the  code  and  architecture  of  the  existing 
TwiddleNet  system  necessary  to  accomplish  the  stated  objective.  Work  will  be  limited  to 
the  applications  layer  as  the  use  of  techniques  that  require  modified  kernel  modules  and 
network  card  drivers  are  not  possible  on  the  devices  available  to  the  student. 

G.  ORGANIZATION 

The  rest  of  this  document  is  organized  as  follows.  Chapter  II  covers  background 
information  on  the  TwiddleNet  system  and  related  work  in  the  area  of  privacy  protections 
for  mobile  networks.  Chapter  III  outlines  the  design  of  the  new  version  of  TwiddleNet 
while  Chapter  IV  details  implementation  aspects  of  the  privacy  protection  measures. 
Chapter  V  concludes  and  discusses  future  work. 
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II.  BACKGROUND 


A.  TWIDDLENET  OVERVIEW 

TwiddleNet  is  a  distributed  system  of  mobile  devices.  The  system  harnesses  the 
power  of  today’s  mobile  devices  to  create  a  network  of  mobile  personal  servers.  The 
content  capture  and  networking  capabilities  of  the  devices  allow  TwiddleNet  users  to 
capture  and  publish  information  in  real  time,  while  at  the  same  time  retaining  ownership 
control  of  published  content.  In  this  way,  content  is  made  available  that  is  otherwise  not 
readily  accessible  to  anyone  but  the  device  owner. 

Designed  to  be  run  on  handheld  devices,  TwiddleNet  is  most  useful  for  first- 
responder  networking  and  information-sharing  tasks  that  require  immediate  content 
capture  and  dissemination  [22],  The  system  is  well  suited  to  first  responder  applications 
due  to  the  fact  that  it  runs  on  lightweight  devices,  can  be  set  up  quickly,  and  supports 
real-time  information  exchange. 

The  following  is  a  brief  overview  of  the  major  components  that  make  up 
TwiddleNet  and  how  they  work  together  in  a  typical  information-sharing  scenario. 

1.  Client 

A  TwiddleNet  Client  consists  of  the  Client  software  running  on  a  mobile  device. 
The  current  implementation  runs  on  HP  iPAQ  hw6945  smartphones  with  the  Windows 
Mobile  5  operating  system,  utilizing  the  .NET  2.0  Compact  Framework.  The  Client  has 
three  primary  functions:  1)  to  create  metadata  for  new  content  and  notify  the  Portal  of  its 
availability,  2)  to  provide  an  interface  for  a  user  to  discover  and  download  new  content, 
and  3)  to  serve  content  to  other  Clients. 

2.  Portal 

The  TwiddleNet  Portal  consists  of  the  Portal  software  running  on  a  standard  PC 
running  any  Windows  operating  system  capable  of  supporting  the  .NET  2.0  Framework. 
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In  the  current  implementation,  the  Portal  is  typically  run  on  an  OQO  ultra  mobile  PC, 
which  is  more  portable  than  a  laptop  or  desktop  computer  [23]. 

The  Portal’s  primary  function  is  to  act  as  a  gateway  to  the  network  of  mobile 
devices.  It  acts  as  a  central  repository  for  metadata  describing  shared  content.  Using  the 
Client  software,  a  user  can  search  for  specific  content  among  the  metadata  residing  on  the 
Portal.  The  Portal  also  houses  information  on  all  TwiddleNet  users  and  keeps  track  of  the 
IP  address  currently  assigned  to  each  user’s  device.  Additionally,  the  Portal  can  cache 
content,  temporarily  taking  on  content  serving  duties,  thus  easing  the  burden  on  resource- 
strapped  clients. 

3.  Command  Post 

The  Command  Post  is  a  program  that  performs  some  of  the  functions  of  a 
TwiddleNet  Client.  It  is  meant  to  run  on  a  Windows  laptop  or  desktop  PC.  The 
Command  Post  is  capable  of  receiving  TwiddleNet  alerts  and  automatically  retrieves  the 
content  associated  with  each  alert  it  receives.  It  then  builds  web  pages  displaying  that 
content.  The  web  server  software  that  hosts  the  content  is  collocated  on  the  machine 
running  the  Command  Post  software. 

The  Command  Post  is  envisioned  to  be  used  at  a  command  center  or  headquarters. 
It  is  intended  to  serve  as  a  situational  awareness  tool  providing  real-time  information  to 
the  commander  of  an  operation  in  order  to  facilitate  timely  decision  making. 

4.  TwiddleNet  Operation 

When  a  user  has  content  to  share,  he  places  the  content  in  a  designated  directory 
in  the  device’s  file  system.  This  may  be  done  manually  by  the  user  or  automatically  by 
the  camera  software  on  the  user’s  device,  for  example.  The  TwiddleNet  Client  software 
monitors  this  directory  and  automatically  generates  metadata  for  the  content  according  to 
the  user’s  preferences.  This  metadata  is  then  sent  to  the  Portal,  serving  as  a  notification 
that  new  content  is  available  (Figure  1,  Step  1).  The  metadata  is  in  XML  format  and 
includes  descriptive  items  (or  “tags”),  such  as  the  username  of  the  creator/publisher,  file 

name,  file  size,  etc.,  as  well  as  user  defined  tags.  A  full  description  of  the  metadata 
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generation  process  is  given  in  [24],  See  also  [25]  for  details  on  a  specialized  user-defined 
tagging  scheme  for  medical  personnel  engaged  in  triage  work. 

Once  the  Portal  receives  metadata  for  new  content,  it  alerts  other  Clients  via 
another  XML -based  message  containing  the  metadata,  notifying  them  that  new  content  is 
available  (Figure  1,  Step  2).  The  Client  software  displays  a  notification  to  the  user  upon 
receipt  of  such  an  alert.  The  user  can  then  choose  to  download  the  content  (Figure  1, 
Step  3).  The  download  will  be  via  an  HTTP  GET  method,  normally  directly  from  the 
publisher  of  the  content,  unless  the  content  is  cached  on  the  Portal.  As  previously 
mentioned,  content  may  be  temporarily  cached  on  the  Portal  due  to  power  or  bandwidth 
limitations  on  the  part  of  the  publisher’s  device.  In  the  case  that  content  is  cached,  the 
Portal  will  retrieve  the  content  from  the  publishing  device  using  the  same  mechanism. 
See  [25]  for  a  detailed  description  of  the  caching  process. 
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Figure  1.  TwiddleNet  System  Operation 
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B.  RELATED  WORK  IN  PRIVACY  PROTECTION  FOR  MOBILE 
NETWORKS 

This  section  outlines  some  common  techniques  found  in  the  literature  for 
providing  privacy  protection  in  mobile  networks. 

1.  Anonymity 

Anonymity  can  be  used  to  provide  identity  protection  for  users.  It  should  be 
noted  that  identity  privacy  is  closely  linked  with  location  privacy:  If  an  attacker  cannot 
correlate  an  identifier  with  a  particular  user  as  that  user  moves  around  in  the  network, 
then  the  attacker  cannot  track  that  user’s  location. 

Numerous  examples  of  anonymity  being  employed  in  mobile  networks  can  be 
found  in  the  literature.  Aura  and  Zugenmaier  mention  the  use  of  proxies  to  provide 
anonymity  [8].  When  a  proxy  (or  any  network  address  translation  device)  is  used,  traffic 
from  multiple  users  behind  the  device  appears  to  be  originated  at  one  address.  In  this 
way,  a  user  can  “hide  in  the  crowd”  among  the  group  of  users  behind  the  proxy.  An 
attacker  cannot  discern  one  user’s  traffic  from  another’s  based  solely  on  identifiers  such 
as  IP  or  MAC  address  since  all  traffic  is  coming  from  the  address  of  the  proxy.  It  should 
be  noted  that  this  technique  alone  cannot  prevent  an  attacker  from  identifying  a  user 
through  traffic  analysis  or  indirectly  through  the  context  of  the  communication  if  the 
actual  content  of  the  communication  is  accessible. 

Digital  mixes  can  also  provide  anonymity.  Askwith,  Merabti,  Shi,  and  Whiteley 
propose  the  use  of  a  digital  mix  network  in  the  Global  System  for  Mobile 
Communications  (GSM)  [9],  A  digital  mix  enables  two  parties  to  communicate  without 
unauthorized  parties  being  able  to  determine  either  the  message  content  or  the  source  and 
destinations  of  the  messages.  Thus,  a  user  can  communicate  anonymously  through  a 
digital  mix  network. 

The  solution  presented  in  [10]  makes  use  of  the  Host  Identity  Protocol  (HIP)  [26]. 
HIP  allows  anonymous  identifiers  to  be  created  by  end  users.  Users  can  communicate 
anonymously  to  other  HIP  enabled  nodes  using  these  identifiers. 
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2.  Pseudonyms 


Pseudonyms  are  often  used  to  protect  identity  privacy,  and  thereby,  location 
privacy,  in  mobile  networks.  In  Wireless  Local  Area  Networks  (WLANs),  the 
pseudonym  is  normally  in  the  form  of  a  temporary  identifier,  such  as  an  IP  or  MAC 
address.  In  the  implementation  discussed  in  [27],  temporary  disposable  MAC  addresses 
are  used.  Each  time  a  client  creates  a  new  association  with  an  access  point  it  randomly 
generates  a  new  valid  MAC  address  to  use  during  that  session.  A  similar  idea  is 
presented  in  [28]  where  a  client  is  given  IP  and  MAC  addresses  by  the  access  point  from 
a  pool  of  valid  addresses  each  time  a  new  association  is  created.  The  idea  here  is  that  by 
frequently  changing  these  unique  identifiers,  an  attacker  would  not  be  able  to  link 
different  communications  to  a  specific  user  or  track  that  user  as  he  changes  locations 
within  the  network. 

Pseudonyms  are  also  used  in  Wireless  WWANs.  In  GSM  a  pseudonym  called  the 
Temporary  Mobile  Subscriber  Identity  (TMSI)  is  used  to  protect  the  International  Mobile 
Subscriber  Identity  (IMSI)  on  the  radio  path  [15].  In  a  similar  manner  to  that  described 
above,  the  TMSI  can  be  changed  for  every  call  setup. 

3.  Encryption 

Encryption  is  commonly  used  to  provide  content  privacy  in  wireless  networks. 
For  instance,  the  Wired  Equivalent  Privacy  (WEP)  and  WiFi  Protected  Access  (WPA) 
encryption  protocols  are  heavily  used  in  802.11  based  WLANs.  The  keys  used  by 
encryption  protocols  can  also  be  used  in  support  of  authentication. 

Encryption  can  also  provide  identity  privacy  by  hiding  identifiers  in  the 
application  layer.  Identifiers  like  e-mail  user  names  would  be  hidden  in  encrypted  traffic 
preventing  an  attacker  from  associating  the  traffic  with  a  particular  user  [28], 

Furthermore,  if  transport  layer  identifiers,  like  port  numbers,  are  hidden, 
encryption  can  mask  the  type  of  communication  (e-mail,  web  browsing,  etc.)  being 
conducted.  This  can  make  it  more  difficult  for  an  attacker  to  identify  a  particular  user 
based  on  knowledge  of  past  activity. 
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4. 


Virtualization 


Virtualization  has  been  used  as  a  technique  to  protect  user  privacy  in  IP  based 
networks.  While  most  work  in  this  area  does  not  address  mobile  networks  specifically, 
some  could  be  applied  to  WLANs  at  least,  if  not  WWANs  as  well,  provided  the  mobile 
devices  involved  are  capable  of  running  the  software  required.  These  software 
requirements  typically  include  running  modified  kernel  modules  and/or  modified  network 
drivers  or  virtual  machine  monitors  (VMMs),  virtual  network  interfaces,  and  virtual 
switching  or  routing  software. 

The  approach  used  in  [29]  involves  protocol  stack  virtualization  where  each 
application  being  run  by  a  user  will  have  its  own  virtual  network  stack.  This  partitioning 
scheme  addresses  linkability,  preventing  a  privacy  violation  in  one  application  from 
affecting  others.  Previously  mentioned  techniques  for  protecting  identity  and  location 
privacy  such  as  the  use  of  temporary  addresses  can  be  implemented  in  each  virtual  stack 
on  a  per-application  basis  rather  than  forcing  one  protocol  stack  to  meet  the  needs  of 
various  different  applications. 

Cabuk,  Dalton,  Ramasamy,  and  Schunter  use  existing  technologies  such  as 
Ethernet  encapsulation,  virtual  LAN  tagging,  and  virtual  private  networks  to  implement 
virtual  network  enclaves  [30].  The  framework  developed  by  the  authors  allows  for 
communication  between  enclaves  to  be  governed  by  an  input  security  model.  While  this 
work  doesn’t  specifically  address  privacy  issues,  in  theory  a  system  such  as  this  could  be 
used  to  provide  separation  between  groups  of  users  in  a  mobile  network  in  order  to 
provide  privacy  protection. 
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III.  DESIGN 


A.  OVERVIEW 

Since  the  TwiddleNet  system  operates  at  the  application  layer,  the  strategy  for  this 
implementation  focuses  on  the  application  layer.  The  design  for  this  work  is  such  that 
privacy  protection  can  be  achieved  by  modifying  the  TwiddleNet  software  in  order  to 
change  the  system’s  behavior.  The  system  was  modified  so  that  users  can  be  partitioned 
into  groups  and  information  can  be  shared  with  only  the  groups  desired  by  the  sharing 
user,  thus  providing  privacy  protection.  An  application  layer  implementation  is 
preferable  to  other  strategies  mentioned  in  Chapter  II,  which  require  changes  at  lower 
levels,  because  all  the  application  program  code  is  available  for  inspection  and 
modification.  Furthermore,  programming  at  the  application  layer  in  a  high-level 
language,  such  as  that  used  to  create  the  TwiddleNet  software,  most  closely  matches  the 
abilities  of  the  author;  the  author  is  familiar  with  application  development,  but  has  little 
experience  with  operating  system  or  device  driver  development. 

The  design  of  this  implementation  makes  use  of  a  network  virtualization  approach 
that  allows  TwiddleNet  users  to  be  partitioned  into  logical  groups  that  can  be  combined 
to  form  virtual  networks  in  arbitrary  combinations.  Consider  the  following  scenario  as  an 
example.  Suppose  firefighters,  medical  personnel,  and  police  are  using  TwiddleNet  in 
response  to  a  mass-casualty  incident.  These  users  can  be  placed  into  separate  groups 
according  to  their  role  along  with,  for  instance,  an  additional  group  for  a  command  center 
at  a  hospital.  The  medical  personnel  wish  to  keep  patient  info  they  collect  private 
allowing  only  other  medical  personnel  and  the  command  center  to  have  access  to  it.  The 
medics  will  configure  their  devices  to  share  information  only  with  their  own  group  and 
the  command  center  group.  This  effectively  creates  a  separate  virtual  network,  inclusive 
of  only  the  medical  and  command  center  users,  on  top  of  the  physical  TwiddleNet 
network.  Users  in  the  firefighter  and  police  groups,  which  are  outside  of  this  virtual 
network,  will  be  unaware  of  any  information  passed  by  medical  personnel. 
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The  following  figures  illustrate  the  user-partitioning  effect.  Previous 
implementations  of  TwiddleNet  did  not  allow  for  any  user  groups,  and  therefore,  all  users 
where  essentially  in  a  single  group  as  depicted  in  Figure  2.  As  Figure  3  shows,  the  new 
implementation  allows  users  to  be  organized  into  multiple  groups  while  remaining 
connected  to  the  same  physical  network.  A  user  in  one  group  can  select  other  groups  to 
share  content  with,  dynamically  creating  virtual  networks  of  groups  as  needed. 


Figure  2.  In  previous  implementations  all  users  were  in  the  same  group 
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Figure  3.  This  implementation  allows  for  grouping  of  users 
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B.  DESIGN  ASPECTS 


No  changes  to  the  physical  components  of  the  TwiddleNet  architecture  were 
necessary  for  this  design.  The  new  implementation  of  the  TwiddleNet  system  still 
consists  of  the  Portal,  a  number  of  Client  devices,  and  the  Command  Post.  The 
difference  in  this  implementation  is  in  system  behavior.  The  design  aspects  and 
modifications  made  to  the  major  TwiddleNet  components  in  order  to  implement  user 
groups  are  addressed  here. 

1.  Client 

A  fundamental  aspect  of  this  implementation  is  that  a  TwiddleNet  user  can  share 
information  on  a  per-group  basis.  For  this  to  be  possible  of  course,  the  Client  needs  to  be 
aware  of  what  groups  are  available.  To  achieve  this,  the  user  sign-in  process  was 
modified  to  allow  the  Portal  to  send  group  information  to  the  Client  upon  sign-in.  These 
modifications  are  detailed  in  Chapter  IV.  This  group  information  is  used  to  build  part  of 
the  Client’s  graphical  user  interface  (GUI)  as  described  below.  Transmittal  of  this 
information  on  sign-in  is  appropriate  because  group  information  will  not  change  for  the 
duration  of  the  session.  When  the  user  signs  in,  he  will  receive  group  information  that 
will  be  used  for  the  remainder  of  the  session. 

Some  means  of  indicating  to  the  user  what  groups  are  available  and  allowing  him 
to  select  desired  recipient  groups  is  required  as  well.  A  GUI  was  designed  for  this 
purpose.  Previous  implementations  of  the  TwiddleNet  Client  software  already  had  a 
form-based  System  Setup  GUI  to  allow  the  user  to  set  system  configuration  parameters. 
Ableiter  covers  this  GUI,  including  screenshots  [25].  For  this  design  a  new  tab  was 
added  to  this  form,  labeled  “RecipientOpt,”  short  for  “Recipient  Options.”  Figure  4 
shows  what  this  GUI  would  look  like  on  a  device  running  Windows  Mobile  5. 
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Figure  4.  TwiddleNet  Client  Recipient  Options  tab 

The  new  tab  displays  the  available  TwiddleNet  groups  to  the  user  and  allows  him 
to  specify  the  groups  that  will  receive  a  new  alert  by  selecting  a  checkbox.  By  default, 
the  group  the  user  belongs  to  will  be  checked.  The  list  of  selected  groups  is  saved 
internally  by  the  Client  software  along  with  the  information  from  other  tabs  when  the 
user  presses  the  “OK”  button.  Two  other  buttons  labeled  “All”  and  “None”  were  added 
for  convenience.  These  buttons  can  be  used  to  select  or  deselect  all  of  the  groups  on  the 
list  at  once.  The  combination  of  groups  selected  by  the  user  determines  how  alerts  are 
generated  by  the  Portal,  as  detailed  in  Chapter  IV.  For  consistency  sake,  the  look  and 
feel  of  the  tab,  including  object  colors,  font  style,  and  font  size  were  selected  so  as  to 
match  the  style  used  on  the  other  tabs  in  the  form. 

After  the  user  configures  the  Recipient  Group  options,  this  information  is 
included  in  future  notifications  of  new  content  that  the  Client  sends  to  the  Portal.  This 
indicates  to  the  Portal  the  groups  that  need  to  be  alerted  for  the  new  content.  The  Portal 
will  use  this  information  to  generate  its  alert  address  list  as  discussed  below. 
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2. 


Portal 


a.  Database  Design 


The  TwiddleNet  Portal’s  database  is  absolutely  essential  for  the  operation 
of  the  system  as  a  whole.  The  database  is  used  to  store  important  system  information 
including  user  credentials,  group  membership  information,  data  about  the  devices  being 
used  in  the  system,  such  as  IP  address,  and  metadata  for  content  that  has  been  shared. 
The  work  for  this  implementation  included  a  redesign  of  the  database,  preserving  existing 
functionality  while  adding  the  functionality  necessary  to  support  user  groups.  Formal 
database  design  methods  were  used  in  the  creation  of  this  database,  including  Entity- 
Relationship  (E-R)  and  Relational  modeling.  Details  of  the  design  are  presented  in  the 
Appendix,  including  the  E-R  diagram,  Relational  model,  and  the  Data  Dictionary 
describing  the  database’s  tables  and  attributes  in  detail.  Important  aspects  of  the  database 
are  highlighted  below. 

(1)  Portal  Eisers  Table.  This  table  contains  user  identification 
information  necessary  for  verification  during  the  user  sign-in  process  as  well  as  linking 
users  to  groups  in  order  to  track  group  membership.  The  Portal  Users  Table,  along  with 
the  Belongs  To  and  Group  Tables,  is  fundamental  to  the  user-partitioning  feature  of  this 
implementation. 

(2)  Belongs  To  Table.  This  table  maps  users  to  groups  by  linking 
a  unique  user  identifier  from  the  Portal  Users  Table  with  a  unique  group  identifier  in  the 
Groups  Table.  This  allows  the  Portal  to  know  what  users  belong  in  each  group  so  an 
alert  can  be  properly  addressed  when  it  is  destined  for  a  certain  group. 


the  system. 


(3)  Groups  Table.  This  table  stores  the  various  groups  available  in 


(4)  Uses  Table.  This  table  links  a  particular  user  with  the  device 
he  is  using.  This  is  done  by  linking  a  unique  identifier  for  the  user  from  the  Portal  Users 
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Table  with  a  device  identifier  in  the  Devices  Table.  When  an  alert  needs  to  go  to  a 
specific  user,  the  IP  address  of  the  device  being  used  by  that  user  can  be  retrieved  from 
the  Devices  Table  via  this  linkage. 

(5)  Devices  Table.  This  table  stores  important  identification 
information,  including  IP  address,  for  the  mobile  devices  being  used  in  the  TwiddleNet 
system. 

(6)  Content  Info  Table.  This  table  stores  the  metadata  associated 
with  content  that  has  been  shared. 

(7)  Special  Tags  Table.  This  table  is  meant  to  store  situation- 
specific  information  as  determined  by  the  system  administrators  and  mission  planners 
using  the  system.  The  current  TwiddleNet  implementation  makes  use  of  this  table  to 
store  triage  information  as  detailed  in  [25]. 

The  database  management  system  used  for  this  implementation 
was  MySQL.  This  choice  was  driven  by  the  fact  that  MySQL  is  open-source  and  freely 
available.  Moreover,  MySQL  allows  for  easy  administration  through  the  use  of  tools 
such  as  phpMy Admin  [31]. 

b.  Sign-in  Process 

As  mentioned  above,  the  design  of  the  sign-in  process  was  modified  as 
part  of  this  implementation.  After  verifying  the  user’s  credentials,  instead  of  simply 
sending  an  acknowledgement,  the  Portal  now  performs  a  database  lookup  and  then  sends 
a  list  of  all  available  user  groups,  as  well  as  the  group  to  which  that  particular  user 
belongs,  to  back  to  the  Client.  Details  of  this  process  are  included  in  Chapter  IV. 

c.  Alert  Addressing  Process 

In  previous  TwiddleNet  implementations  the  Portal  would  simply  send  an 
alert  to  all  signed-in  users  when  notified  of  new  content  being  available.  This  required 
the  Portal  to  generate  a  list  of  the  IP  addresses  for  all  active  client  devices.  The  Portal  did 
this  by  retrieving  the  IP  addresses  from  its  database.  In  this  design  the  process  was 
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modified  so  as  to  send  an  alert  only  to  users  in  the  groups  indicated  by  the  user  sharing 
the  content.  The  Portal  now  creates  its  alert  recipient  address  list  by  gathering  the  IP 
addresses  for  users  that  are  signed-in  and  who  belong  to  one  of  the  groups  indicated  in 
the  new  content  notification.  This  process  is  discussed  in  detail  in  Chapter  IV. 

3.  Command  Post 

No  major  changes  to  the  Command  Post  software  were  necessary  for  this 
implementation.  Administratively,  the  Command  Post  was  placed  in  its  own  group  in 
order  to  provide  users  a  means  of  sharing  content  directly  with  it.  The  Command  Post 
won’t  receive  an  alert  unless  the  user  selects  the  Command  Post  group  in  the  GUI  as 
discussed  earlier. 
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IV.  IMPLEMENTATION  AND  TESTING 


A.  IMPLEMENTATION  TOOLS 

1.  Software 

As  this  implementation  builds  upon  past  implementations  which  were  written  in 
the  C#  programming  language,  the  programming  for  this  work  was  also  done  in  C#.  The 
TwiddleNet  Portal  code  is  a  console  application  based  on  the  .NET  2.0  Framework, 
designed  to  be  run  on  a  PC.  The  TwiddleNet  Client  code  is  a  Pocket  PC  application 
based  on  the  .NET  2.0  Compact  Framework,  designed  to  be  run  on  devices  using  the 
Windows  Mobile  5  operating  system. 

Microsoft’s  Visual  Studio  2005  Integrated  Development  Environment  was  used 
for  development  of  the  TwiddleNet  software.  Visual  Studio  is  an  excellent  tool  for 
development  using  .NET-based  languages  like  C#.  When  integrated  with  the  Pocket  PC 
Software  Development  Kit,  Visual  Studio  becomes  a  powerful  platform  for  mobile 
development  with  built-in  tools  for  easy  deployment  of  code  to  the  device  and  emulators 
for  testing  without  an  actual  device. 

The  MySQL  Database  Management  System  was  used  to  host  the  TwiddleNet 
Portal’s  database.  In  this  implementation,  MySQL  was  provided  as  part  of  the  XAMPP 
[32]  software  suite.  XAMPP  is  a  cross-platform  Apache-MySQL-PHP-Perl 
implementation  that  is  very  easy  to  setup  and  use.  Using  XAMPP,  one  can  setup  a  web 
and  database  server  simply  by  downloading  the  software  and  unpacking  it.  The  software 
is  self-contained  and  preconfigured  so  that  the  Apache  web  server  supports  PHP, 
allowing  tools  like  phpMy Admin  to  be  used  out  of  the  box.  Use  of  this  software  suite 
allows  a  TwiddleNet  Portal  to  be  setup  quickly  and  easily. 

A  few  additional  software  tools  are  useful  for  the  creation  and  management  of  the 
TwiddleNet  Portal’s  database.  As  previously  mentioned,  the  Apache  web  server  that  is 
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part  of  the  XAMPP  suite  allows  for  the  use  of  phpMy Admin,  providing  a  web-based 
interface  useful  for  the  administration  of  MySQL  databases.  A  new  database  can  easily 
be  created  using  this  tool. 

Once  an  empty  database  for  the  Portal  has  been  created,  its  structure  must  be 
defined  and  certain  essential  fields  must  be  populated.  Two  SQL  scripts  were  created  for 
this  purpose  (see  the  Appendix).  These  scripts  contain  the  SQL  commands  necessary  to 
create  the  database  structure  and  perform  the  initial  population.  Once  these  scripts  have 
been  run,  the  Portal  database  is  ready  for  use. 

Taking  advantage  of  the  Apache  web  server  included  in  the  XAMPP  package,  a 
web-based  interface,  written  in  PHP,  was  created  to  simplify  the  management  of  the 
TwiddleNet  Portal  database.  This  administration  web  page  can  be  used  to  create  new 
TwiddleNet  users  and  groups,  assign  users  to  groups,  add  devices  to  the  database,  and 
assign  users  to  devices.  Examples  of  the  interface  are  seen  in  Figures  5  and  6.  Figure  5 
shows  what  the  User  Listing  page  looks  like  and  Figure  6  shows  the  page  that  is  used  to 
add  a  new  user. 
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Figure  5.  TwiddleNet  Portal  Database  Admin  Page,  User  Fisting 
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TwiddleNet  Admin:  Add  User 
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Figure  6.  TwiddleNet  Portal  Database  Admin  Page,  Creation  of  New  User 

2.  Hardware 


The  mobile  devices  used  to  run  the  TwiddleNet  Client  software  are  HP  iPAQ 
hw6945  smartphones.  These  devices  are  quite  powerful  with  a  large  touch  screen 
display,  Qwerty  keyboard,  and  multiple  networking  interfaces  including  WiFi  (802. 1 1 
WLAN),  GSM  (WWAN),  and  Bluetooth  (PAN).  The  devices  use  the  Windows  Mobile  5 
operation  system  and  run  software  based  on  the  .NET  Compact  Framework. 

The  TwiddleNet  Portal  can  be  run  on  any  Windows  machine  capable  of 
supporting  the  .Net  2.0  Framework.  During  development  and  testing  this  was  typically  a 
Windows  XP  laptop  or  an  OQO  Ultra  Mobile  PC  also  running  Windows  XP.  The  small 
size  and  portability  of  the  OQO  makes  it  convenient  for  use  in  a  mobile  system  like 
TwiddleNet. 

For  demonstration  and  testing  the  TwiddleNet  machines  are  provided  IP  addresses 
via  the  Dynamic  Host  Configuration  Protocol  (DHCP).  A  laptop  running  Windows 
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Server  2003  is  used  for  this  purpose.  For  convenience,  the  Command  Post  software  is 
also  run  on  this  machine  along  with  the  Apache  web  server  that  supports  it. 

In  the  lab  an  802.11  access  point  is  typically  used  to  create  a  stand-alone  WiFi 
network  for  demonstration  and  testing.  In  actual  usage  an  access  point  in  a  host  network 
or  some  form  of  mobile  access  point  may  be  utilized. 

3.  Lab  Network 

Figure  7  shows  how  the  TwiddleNet  system  is  arranged  in  the  lab  for  testing  and 
demonstration  purposes.  The  access  point  creates  a  stand-alone  WiFi  network.  The 
DHCP  server  provides  IP  addresses  to  the  various  components.  The  Access  Point,  Portal, 
and  Command  Post  use  reserved  addresses  while  the  Clients  receive  address  dynamically 
from  a  specific  range. 
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Figure  7.  TwiddleNet  Lab  Network 


26 


B. 


NEW  TWIDDLENET  SYSTEM  OPERATION 


1.  Overview 

The  following  is  a  high-level  overview  of  the  new  TwiddleNet  System  operation. 
Figure  8  illustrates  the  user-partitioning  feature  of  the  new  implementation.  Here  the 
Client  devices  are  organized  into  three  separate  groups  instead  of  a  single  group  as  in 
Figure  1. 


1 ,  Oliflnt  in  Gmiip  A  with 
new  content  shares  to 


Group  A 


2.  Portal 
sends  alert 
to  users  in 
Group  C  and 
Command 
Post  only  , 
Users  in 
Groups  A 
and  B-  are 
not  notified, 


Group  B 


Group  C 


Command  post 


Figure  8.  New  TwiddleNet  System  Operation 


The  new  system  operation  can  be  illustrated  using  an  information  sharing  scenario 
like  that  discussed  in  Chapter  II.  Here,  unlike  in  the  previous  discussion,  the  TwiddleNet 
users  are  broken  up  into  separate  groups,  named  A,  B,  and  C,  for  the  purpose  of 
discussion.  The  Command  Post  is  assigned  to  a  separate  group  on  its  own.  In  this 
scenario  a  user  in  Group  A  wishes  to  share  content  with  users  in  Group  C  and  the 
Command  Post  but  not  with  other  users  in  Group  A  or  with  those  in  Group  B. 
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The  scenario  begins  with  the  user  starting  the  TwiddleNet  Client  software  and 
signing  into  the  Portal.  By  the  time  the  sign-in  process  is  complete,  the  Client  will  have 
received  the  group  information  necessary  to  populate  the  Recipient  Options  tab  of  the 
System  Setup  GUI  (discussed  in  Chapter  III)  from  the  Portal.  The  user  would  then  select 
Group  C  and  the  Command  Post  group  while  leaving  Groups  A  and  B  unselected.  Now 
the  Client  software  is  configured  according  to  the  user’s  preferences  for  alert  recipients. 

When  the  user  shares  content,  like  in  previous  implementations,  a  notification  is 
sent  to  the  Portal  containing  metadata  for  the  shared  content.  In  the  new  implementation 
this  metadata  also  contains  the  groups  specified  by  the  user  for  alert  receipt,  namely 
Group  A  and  the  Command  Post  group  (Figure  8,  Step  1). 

After  the  Portal  receives  the  notification  of  new  content,  it  sends  an  alert  to  the 
Clients  in  the  specified  groups  only,  instead  of  all  other  active  Clients.  So  Clients  in 
Group  C  and  the  Command  Post  are  notified  that  new  content  is  available  (Figure  8,  Step 
2).  Other  users  in  Group  A  as  well  as  those  in  Group  B  will  not  receive  an  alert  and  will 
therefore  not  have  access  to  that  content.  After  receiving  an  alert,  a  user  wishing  to 
download  the  content  may  do  so  as  discussed  in  Chapter  II. 

2.  System  Operation  Description 

This  section  contains  a  more  detailed  description  of  important  aspects  of  the  new 
TwiddleNet  System  operation.  For  the  purposes  of  this  discussion  the  information¬ 
sharing  process  is  broken  down  into  the  four  major  steps:  1)  sign-in,  2)  Recipient  Options 
configuration,  3)  notification  of  new  content,  and  4)  alert  generation  and  transmittal. 

a.  Sign-in 

The  sign-in  process  (illustrated  in  Figure  9)  begins  with  the  user  entering 
his  user  name  and  password  when  prompted  by  the  TwiddleNet  Client  software  running 
on  the  handheld  device.  The  Client  then  creates  a  TCP  connection  with  the  Portal  and 
sends  the  user  name  and  password  entered  by  the  user,  the  device’s  MAC  addresses,  and 
two  hash  values,  for  the  user  name  and  password,  respectively.  The  hashed  user  name  is 

used  as  a  unique  identifier  for  Portal  Users  records  in  the  Portal’s  database  (see 
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Appendix).  As  a  security  precaution,  the  Portal  stores  a  hash  value  of  the  password  to 
avoid  keeping  a  plain-text  version.  The  MAC  address  is  currently  not  used,  but  was 
considered  by  previous  TwiddleNet  developers  to  be  potentially  useful  for  future 
software  features. 

After  receiving  this  information  the  Portal  processes  it.  The  first  step  in 
processing  is  to  validate  the  user  by  comparing  the  user  name  and  password  hashes  it  was 
passed  to  those  stored  in  its  database.  If  the  passed-in  values  don’t  match,  the  Portal  will 
send  an  error  message  to  the  Client.  The  Client  will  then  prompt  the  user  to  try  the  sign- 
in  again  or  quit. 

If  the  user  is  successfully  validated,  the  Portal  will  then  check  the  device 
IP  address  stored  in  the  Devices  record  (see  Appendix)  associated  with  the  user  and 
update  it  if  necessary  (the  Portal  has  access  to  the  device’s  current  IP  address  via  the  TCP 
connection).  This  is  one  way  in  which  the  Portal  keeps  track  of  the  current  IP  address  of 
active  devices.  For  further  details  on  Client  IP  address  tracking  see  [25]. 

Next,  the  Portal  will  retrieve  the  name  of  the  group  the  user  belongs  to  as 
well  as  a  list  of  all  existing  groups.  This  information  is  then  sent  to  the  Client  along  with 
an  acknowledgement  message  to  indicate  successful  sign-in.  The  Client  will  store  this 
group  information  internally  and  use  it  to  build  the  Recipient  Options  tab  on  the  System 
Setup  GUI  as  discussed  in  Chapter  III. 


Figure  9.  User  Sign-in  Process 
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b.  Recipient  Options  Configuration 


As  previously  mentioned,  the  TwiddleNet  Client  software  uses  the  group 
information  it  receives  from  the  Portal  as  part  of  the  sign-in  process  to  build  the  Recipient 
Options  GUI  (see  Figure  4)  that  the  user  will  use  to  indicate  which  groups  should  receive 
alerts  for  future  shared  content.  By  default,  only  the  user’s  group  will  be  selected,  so  if 
he  makes  no  configuration  changes,  content  will  be  shared  only  with  the  other  users  in  his 
group.  If  the  user  desires  to  share  with  groups  other  than  his  own,  he  will  call  up  the 
Recipient  Options  configuration  and  select  additional  groups.  If  all  groups  are  selected,  a 
special  flag  is  set  indicating  the  content  is  public.  After  the  user  presses  the  “OK”  button, 
the  selected  group  names  will  be  saved  internally  for  future  use  by  the  Client  software 
when  building  notifications  destined  for  the  Portal. 

c.  Notification  of  New  Content 

When  a  user  shares  content,  the  TwiddleNet  Client  software  builds  a 
notification  message  for  that  item.  This  message  is  in  XML  format  and  includes 
metadata  describing  the  content  as  well  as  the  recipient  group  information  saved  earlier. 
An  example  of  a  notification  message  is  shown  below. 


<?xml  version=" 1 . 0 "  encoding="ut f-8 " ?> 

<TNetMessage> 

<content> 

<user_name>Teamla</user_name> 

<task>SHARE</task> 

<tags> 

<filename>T-Ten0016 . jpg</ filename> 

<f ile_size>171805</ f ile_size> 

<f ile_type> jpg</f ile_type> 

<public>True</public> 

<date_created>2008-09-24T16 : 49 : 24</date_created> 
<date_shared>2009-01-15T12 : 09 : 54</date_shared> 
<rec_groups> 

<group_list> 

<gr oup_name 1 >CommandP  o  s t  < / gr oup_name 1 > 
<group_name2>Fire  Fighters</group_name2> 
<group_name3>Medics</group_name3> 
<group_name4>Police</group_name4> 
</group_list> 

</ rec_groups> 
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<special_tags> 
</ special_tags> 
</tags> 

</ content> 
</TNetMessage> 


This  example  shows  that  a  picture  (T-Ten0016.jp)  has  been  shared  with 
four  groups  included  in  the  <group_list>  tag.  These  four  groups  happen  to  represent  all 
the  groups  implemented  in  the  system  so  the  <public>  tag  contains  the  value  “True.”  The 
value  of  this  flag  affects  the  behavior  of  the  Portal  when  it  processes  notifications  as 
discussed  below. 

After  the  notification  message  has  been  built,  the  Client  opens  a  TCP 
connection  with  the  Portal  and  sends  the  message.  The  Portal  parses  and  stores  the 
metadata  contained  in  the  message,  then  responds  with  an  acknowledgement  or  an  error 
message  if  the  notification  couldn’t  be  processed  properly.  When  the  Client  receives  an 
acknowledgement,  the  GUI  is  updated  indicating  the  content  was  successfully  shared. 
Otherwise  an  error  message  is  displayed  to  the  user.  The  notification  process  is 
illustrated  in  Figure  10. 


Figure  10.  Client-Portal  Notification  Process 
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d.  Alert  Generation  and  Transmittal 

When  the  Portal  receives  a  notification  message  for  new  content,  it  must 
process  the  information.  This  includes  parsing  the  message  and  storing  the  metadata 
found  therein  in  a  new  Contentlnfo  record  in  its  database  (see  Appendix).  The  Portal  also 
stores  the  recipient  groups  contained  in  the  notification  message  internally  for  future  use 
in  alert  generation. 

After  the  incoming  information  has  been  processed,  the  Portal  builds  the 
alert  message  that  will  be  sent  to  other  users  alerting  them  of  the  availability  of  new 
content.  The  alert  message  is  also  an  XML  message  in  the  same  format  as  the 
notification  message.  Unlike  in  previous  implementations  where  the  Portal  simply  sent 
an  alert  to  each  active  user,  here  the  Portal  sends  the  alert  only  to  the  users  belonging  to 
the  groups  specified  in  the  notification  message.  In  order  to  achieve  this  the  Portal  uses  a 
nested  SQL  query  to  first  pull  the  user  names  belonging  to  the  groups  included  in  the 
notification  message  from  its  database,  and  then  pull  the  IP  addresses  associated  with  the 
devices  assigned  to  all  active  users  in  that  list.  The  result  is  a  list  containing  the  IP 
address  associated  with  the  device  being  used  by  each  user  belonging  to  the  recipient 
groups  indicated  by  the  user  sharing  the  content. 

After  the  IP  address  list  has  been  generated,  the  Portal  sends  the  alert 
message  to  each  user’s  Client  via  the  address  for  their  device  on  the  list.  As  in  previous 
implementations,  this  is  done  in  a  multithreaded  manner  freeing  the  main  Portal  process 
so  that  it  may  handle  other  communications  and  ensuring  that  alerts  are  sent  in  a  timely 
manner. 

C.  IMPLEMENTATION  ISSUES 

In  this  section  notable  implementation-specific  issues  are  discussed.  For  this 
implementation  a  few  changes  were  necessary  to  address  issues  and  make  improvements 
in  the  TwiddleNet  code.  Theses  changes  involved  the  use  of  hash  functions  as  well  as 
XML  parsing  methods. 
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1. 


Hash  Functions 


In  the  previous  implementation  a  .NET-specific  hash  function  was  used  to 
generate  hash  values  for  user  names  and  passwords.  This  did  not  pose  a  problem  in  the 
past  because  the  only  software  that  handled  these  values  was  based  on  the  .NET  libraries. 
The  new  implementation,  however,  allows  for  user  records  of  the  Portal  database, 
including  user  name  and  password  hashes,  to  be  created  using  the  previously  mentioned 
web-based  administration  interface.  When  user  records  are  created  using  this  tool,  hash 
values  must  be  created  using  functions  available  in  PHP.  Since  the  algorithm  used  by  the 
.NET  hash  function  was  unknown,  and  therefore  impossible  to  replicate  using  PHP,  the 
author  was  unable  to  create  a  hash  value  in  PHP  that  matched  the  value  produced  by  the 
.NET  function  when  hashing  the  same  string.  This  affected  the  user  sign-in  process,  as 
user  validation  was  impossible  for  users  created  via  the  web-based  administration  tool. 
Since  MD5  hashes  can  be  created  in  both  .NET  and  PHP,  the  TwiddleNet  code  was 
modified  to  use  an  MD5  hash  function.  In  this  way  a  string,  such  as  a  user  name  or 
password,  when  hashed  by  a  PHP  function,  produces  the  same  value  as  that  produced  by 
the  .NET  hash  function  when  hashing  the  same  string,  and  can  be  compared  during  user 
validation  without  problems. 

2.  XML  Parsing 

Much  of  the  Client-Portal  communication  in  TwiddleNet  relies  on  the  use  of 
XML.  Consequently,  the  Client  and  Portal  code  must  be  able  to  parse  XML  documents 
in  order  to  retrieve  the  information  embedded  within.  The  previous  implementation  was 
rather  inflexible  in  the  manner  in  which  this  parsing  was  implemented.  The  code  that 
parsed  an  XML  document  depended  heavily  on  the  structure  of  the  document.  It  used 
nested  if-else  statements  that  corresponded  directly  to  the  structure  of  the  XML 
document.  In  other  words,  if  the  XML  document  had  tags  that  were  nested  three  levels 
deep,  the  parsing  code  had  to  have  if-else  statements  nested  three  levels  deep.  Thus,  any 
change  to  the  structure  of  the  XML  document  necessitated  a  great  deal  of  work  changing 
the  parsing  code. 
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The  issue  was  addressed  in  this  implementation  through  the  use  of  a  recursive 
XML  parsing  method.  This  makes  the  parsing  code  independent  of  the  structure  of  the 
XML  document  itself.  The  method  can  parse  an  XML  document  no  matter  how  many 
levels  of  nesting  are  used.  Furthermore,  the  code  does  not  need  to  be  rewritten  if  the 
structure  of  the  XML  document  is  changed.  This  will  ease  the  burden  on  programmers  as 
future  changes  are  made  to  the  system. 

D.  TESTING 

The  new  TwiddleNet  implementation  was  tested  in  January  2009  as  part  of  the 
Cooperative  Operations  and  Applied  Science  and  Technology  Studies  (COASTS)  Field 
Experiment  II  (FEX-II)  at  Camp  Roberts,  California.  TwiddleNet  researchers  have  been 
involved  with  the  COASTS  project  for  some  time  as  it  provides  an  excellent  test  bed. 
The  COASTS  field  experiments  give  researchers  an  opportunity  to  run  TwiddleNet  in  a 
real-world  environment  outside  the  confines  of  the  lab. 

Rather  than  being  run  in  its  own  self  contained  network,  as  it  is  for  lab  testing  and 
demonstration,  during  the  FEX  TwiddleNet  was  integrated  into  the  greater  Camp  Roberts 
network.  Figure  11  shows  how  the  TwiddleNet  network  was  arranged  during  the  FEX 
testing. 


34 


Satellite  Link 


Access  Point 


Command 
Post  r- 


Clients 


TwiddleNet 

Gateway 

10.11.72.30 


Wired  Network, 

(10,115.1/24) 


Camp  Roberts 


WiFi  Network 
(10.11,72,1/24) 


\ 


NPS 


VPN  Router 


10,11,5,1 


10,  tl  72 ,1 


VPN  Router 


Figure  11.  TwiddleNet  Integration  into  Camp  Roberts  Network 


TwiddleNet  was  assigned  a  block  of  addresses  belonging  to  the  Camp  Roberts 
network  for  use  during  the  FEX.  All  TwiddleNet  components  were  assigned  static 
addresses  from  this  block  as  seen  in  Figure  11.  An  access  point  was  available  to  provide 
connectivity  via  WiFi. 

The  user-partitioning  feature  of  the  new  TwiddleNet  implementation  was 
successfully  tested  during  the  FEX.  Users  were  organized  into  three  different  groups  and 
content  was  shared  to  various  combinations  of  groups.  The  only  difficulty  experienced 
had  to  do  with  the  distance  of  devices  from  the  access  point.  If  the  devices  were  more 
than  approximately  60  yards  away,  content  transfers  between  the  devices  and  from  the 
devices  to  the  Command  Post  failed.  It  is  believed  that  this  is  due  to  the  relatively  lower 
signal  strength  at  the  periphery  of  the  access  point’s  coverage  range. 

Another  notable  aspect  of  the  FEX  testing  centered  on  a  new  tool  called  the 
TwiddleNet  Gateway.  The  TwiddleNet  Gateway  is  a  piece  of  software  that  interfaces 
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TwiddleNet  with  external  systems  allowing  content  to  be  shared  from  sources  other  than 
TwiddleNet  Clients.  While  not  necessarily  related  to  the  work  done  for  this  thesis  on 
privacy  protection,  the  Gateway  software  does  take  advantage  of  the  user-partitioning 
feature  developed  as  part  of  this  work.  This  allows  the  Gateway  to  share  content  it 
receives  from  external  sources  with  TwiddleNet  users  on  a  per-group  basis  much  like  a 
standard  TwiddleNet  Client  can. 

The  TwiddleNet  Gateway  was  included  as  part  of  the  TwiddleNet  network  during 
the  FEX  testing  (see  Figure  11).  Content  was  shared  with  the  Gateway  over  a  VPN 
connection  with  the  wireless  lab  at  the  Naval  Postgraduate  School  (NPS)  using  the 
External  System  Simulator  (ESS).  The  ESS  is  a  simple  program  designed  to  simulate  a 
content  feed  that  might  be  provided  from  an  external  system.  The  ESS  provides  a 
notification  of  new  content  to  the  Gateway,  which  then  retrieves  the  content  and  shares  it 
with  other  TwiddleNet  users. 

Overall  the  FEX  testing  was  very  successful.  The  ease  at  which  TwiddleNet  is 
able  to  be  integrated  into  other  networks  like  the  Camp  Roberts  network  is  due  in  no 
small  part  to  the  decisions  made  by  previous  designers,  who  chose  to  base  all  TwiddleNet 
communications  on  universal  standards  such  as  TCP/IP  and  HTTP. 
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V.  CONCLUSION  AND  FUTURE  WORK 


A.  CONCLUSION 

This  work  successfully  implemented  privacy  protection  for  TwiddleNet,  a 
network  of  mobile  devices  intended  for  use  by  first  responders.  As  the  user-partitioning 
feature  of  this  implementation  shows,  network  virtualization  is  an  appropriate  choice  for 
implementing  privacy  in  mobile  networks. 

As  discussed  in  Chapter  I,  this  work  focused  on  the  requirement  of  content 
privacy.  This  implementation  partially  meets  this  requirement  in  that  content  is  protected 
from  inadvertent  release  to  unauthorized  users,  but  not  protected  from  eavesdropping.  In 
other  words,  the  threat  from  casual  observers  is  addressed,  but  the  attacker  threat  is  not 
addressed.  An  attacker,  with  advanced  knowledge  of  networking  and  the  use  of 
specialized  “sniffing”  tools,  could  still  gain  access  to  content  shared  by  TwiddleNet 
users,  compromising  their  privacy.  Properly  addressing  this  threat  calls  for  a  more 
sophisticated  approach,  perhaps  incorporating  techniques  mentioned  in  Chapter  II,  and  is 
left  to  future  work. 

In  just  a  few  short  years  TwiddleNet  has  become  a  robust  and  useful  system, 
improving  with  each  incremental  development  step  in  order  to  better  meet  the  needs  of 
first  responders.  This  work  realizes  the  latest  step  forward  in  that  progression.  It  is  the 
sincere  hope  of  the  author  that  this  progression  continues  for  years  to  come. 

B.  FUTURE  WORK 

This  work  represents  the  first  step  toward  improving  the  overall  security  posture 
of  the  TwiddleNet  System.  Much  more  can  be  done  to  improve  the  privacy,  security,  and 
availability  of  the  system.  Some  ideas  for  future  work  are  presented  below. 
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1. 


End-to-End  Encryption 


Currently,  even  if  mechanisms  such  as  WEP  or  WPA  are  enabled  in  order  to 
protect  content  in  the  wireless  medium,  the  system  could  still  be  vulnerable  to  an  attacker 
capturing  packets  on  any  wired  links.  An  end-to-end  encryption  scheme  utilizing 
technology  like  Secure  Sockets  Layer  (SSL)  could  be  used  to  address  this.  Furthermore, 
encryption  keys  used  in  such  a  scheme  could  also  be  used  in  support  of  authentication. 

The  use  of  SSL  proves  challenging,  however,  due  to  the  implementation  platform 
used  for  the  TwiddleNet  Client  software,  as  the  .NET  Compact  Framework  2.0  does  not 
support  SSL  connections.  Third-party  libraries,  such  as  those  provided  by  UDAParts 
[33],  may  provide  a  way  forward  in  SSL-enabling  TwiddleNet  communications. 

2.  Addressing  the  Single-Point-of-Failure  Issue 

The  TwiddleNet  Portal  represents  a  potential  single-point-of-failure  in  the  system. 
If  the  Portal  fails,  all  content  metadata,  as  well  as  user  and  group  information,  will  no 
longer  be  accessible.  Furthermore,  client  communications  will  no  longer  be  possible  as 
the  Portal  is  central  to  all  sharing,  alerting,  and  transfer  of  content.  Providing  a 
mechanism  for  redundancy  or  making  the  system  architecture  more  distributed  could 
greatly  improve  the  overall  availability  of  the  system. 

3.  Software  Engineering 

The  TwiddleNet  project  could  benefit  greatly  from  a  formal  software  engineering 
effort.  This  should  include  requirements  definition,  use  case  analysis,  and  formal  UML 
documentation.  This  would  not  only  help  newcomers  to  the  project  who  need  to  learn  the 
software,  but  also  would  provide  a  basis  for  future  implementation  on  platforms  other 
than  .NET.  The  design  should  be  done  with  extensibility  in  mind  so  that  future 
modifications  and  additions  are  easier.  In  addition,  the  documentation  should  be  updated 
as  new  features  are  added  or  other  changes  are  made. 
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4. 


Command  Post  Improvements 


A  few  improvements  to  the  Command  Post  software  would  go  a  long  way  toward 
increasing  its  usefulness.  Currently  the  web  page  that  the  software  builds  is  mostly  static. 
There  is  the  ability  to  append  information  to  the  metadata  displayed,  but  no  new  content 
is  shown  until  the  page  is  refreshed.  Implementing  the  page  using  technology  like 
Asynchronous  Java  and  XML  (AJAX)  could  address  this.  With  AJAX,  a  portion  of  a 
web  page  can  be  updated  without  refreshing  the  entire  page. 

The  current  implementation  of  the  Command  Post  is  receive-only  in  that  it 
displays  only  content  shared  from  TwiddleNet  clients  but  cannot  share  content  itself. 
Another  potential  improvement  to  the  software  would  be  to  add  the  ability  to  share 
content  just  like  a  standard  TwiddleNet  Client.  A  technology  like  AJAX  could  possibly 
be  used  here  as  well,  creating  a  web-based  application  that  could  be  used  to  view  content 
and  its  associated  metadata,  update  that  information,  and  send  the  updates  back  out  to 
Clients. 


5.  Integration  with  Other  COASTS  Systems 

There  may  be  great  benefit  derived  from  the  integration  of  TwiddleNet  with  other 
systems  that  are  part  of  the  COASTS  program,  specifically  the  Real-Time  Automated 
Position  Identification  System  (RAPIDS)  and  the  perimeter  security  system  being  tested 
during  COASTS  experiments. 

RAPIDS  is  a  three  dimensional  positioning  system  used  for  situational  awareness 
and  command  and  control  purposes.  Using  RAPIDS,  the  position  of  an  Unmanned 
Aerial  Vehicle  (UAV),  for  example,  can  be  tracked  on  a  common  operational  picture. 
Integrating  TwiddleNet  with  RAPIDS  could  allow  images  taken  from  the  UAV  to  be 
distributed  to  teams  on  the  ground,  potentially  providing  real-time  intelligence  or  other 
tactical  data. 
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TwiddleNet  could  also  be  integrated  with  the  perimeter  security  system  used  in 
COASTS  experiments.  For  example,  TwiddleNet  could  be  used  to  distribute  pictures  of 
contacts  of  interest,  such  as  suspicious  vehicles  or  illegal  immigrants,  to  border  security 
teams. 
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APPENDIX 


TwiddleNet  Portal  Database  Entity-Relationship  Diagram 


TwiddleNet  Portal  Database  Relational  Model 

PortalUsers  (Userid,  UserName,  PswdHash,  Role,  RcvPubAlerts) 
Groups  (Group Id,  GroupName,  MissionNum) 

BelongsTo  ( Userid,  Grougld) 

Devices  (Deviceld,  IPAddr,  MACAddr) 

Uses  ( Userid. .  Deviceld,  TimeSignedln) 
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Missions  (MissionNum.  Description,  Duration,  Location) 


Contentlnfo  (Contentld,  Filename,  FileSize,  FileType,  Public,  Cached,  DateCreated, 
DateShared,  LastRequest,  TagNum,  Userid) 

SpecialTags  (TagNum,  SpecDatal,  ...  ,  SpecDataN) 


TwiddleNet  Portal  Database  Data  Dictionary 


Assumptions 

•  A  user  must  belong  to  at  least  one  group. 

•  Userids  are  unique. 

•  A  user  may  be  sharing  zero  or  more  pieces  of  content  at  any  given  time. 

•  A  particular  file  may  be  shared  by  more  than  one  user,  but  one  Contentlnfo  record  is 
associated  with  only  one  user. 

•  A  user  can’t  share  the  same  content  more  than  once. 

•  A  user  can  only  log  in  to  the  system  from  one  device  at  a  time. 

•  A  device  that  isn’t  being  used  to  run  the  TwiddleNet  application  isn’t  associated  with 
the  system. 

•  A  device  can  only  have  one  IP  address  at  a  given  time  (if  both  WiFi  and  GPRS  radios 
are  enabled  at  the  same  time,  the  device  will  associate  with  the  WiFi  access  point 
only). 

•  A  group  can  only  be  assigned  to  one  mission  at  a  time. 


Data  Dictionary 

Entity:  PortalUsers  -  All  the  users  currently  registered  to  use  TwiddleNet 
Attributes: 

•  Userid  -  A  unique  identifier  for  the  user  signed  into  TwiddleNet. 

•  UserName  -  The  name  of  the  user  identified  by  Userid. 

•  PswdHash  -  The  value  resulting  from  hashing  the  user’s  password. 

•  Role  -  The  role  the  particular  user  plays  within  the  group. 

•  RcvPubAlerts  -  Boolean  value  indicating  whether  or  not  this  user  should  receive 
public  alerts. 

Entity:  Groups  -  The  different  groups  the  users  are  organized  into. 

Attributes: 

•  Groupld  -  A  unique  identifier  assigned  to  the  group. 
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•  GroupName  -  The  name  of  the  group.  Ex:  “Red  Cross”. 

Entity:  Devices  -  The  devices  currently  associated  with  the  system. 

Attributes: 

•  DevicelD  -  A  unique  identifier  for  the  device;  used  for  database  implementation 
purposes. 

•  MACAddr  -  The  MAC  address  of  the  device  being  used  by  the  associated  user. 

•  IPAddr  -  The  IP  address  currently  assigned  to  the  device  being  used  by  the 
associated  user. 

Entity:  Contentlnfo  -  Information  describing  the  content  that  the  associated  user  is 
sharing. 

Attributes: 

•  Contentld  -  A  unique  identifier  for  the  content. 

•  Filename  -  The  filename  of  the  content  being  shared. 

•  FileSize  -  The  size  (in  memory)  of  the  file. 

•  FilesType  -  The  file  extension  of  the  content. 

•  Public  -  A  boolean  indicating  whether  or  not  the  content  should  be  available  to  all 
users  or  just  the  group  associated  with  the  sharer. 

•  Cached  -  A  boolean  indicating  whether  or  not  the  content  is  cached  on  the  Portal. 

•  DateCreated  -  Date  the  content  was  created. 

•  DateShared  -  Date  the  content  was  shared. 

•  LastRequest  -  Date  and  time  the  content  was  last  requested  from  the  sharer. 

Entity:  SpecialTags  -  Extended  information  describing  the  content  specific  to  a  particular 
situation. 

Attributes: 

•  TagNum  -  A  unique  integer  identifying  a  particular  SpecialTags  record. 

•  Only  generic  attributes  are  named  at  this  time.  For  example  SecDatal,  etc.  for 
Special  Data  Items. 

Entity:  Missions 
Attributes: 

•  MissionNum  -  A  unique  identifier  for  the  mission. 

•  Description  -  A  description  of  the  mission.  For  instance,  purpose. 

•  Duration  -  Number  of  hours  the  mission  is  expected  to  last. 

•  Location  -  The  geographic  location  the  mission  is  to  take  place  at. 

Relationships: 

•  BelongsTo  -  Relates  users  to  the  groups  they  belong  to. 

•  Uses  -  Relates  a  user  to  the  device  that  user  is  currently  using. 

o  Attributes: 

■  TimeSignedln  -  The  time  the  user  signed  into  TwiddleNet. 
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•  Shares  -  Relates  particular  Contentlnfo  items  to  the  user  sharing  the  associated 
content. 

•  Contains  -  Relates  SpecialTags  with  the  associated  Contentlnfo. 

•  AssignedTo  -  Relates  missions  with  groups  that  are  performing  them. 


Portal  Database  SQL  Scripts 

Script  to  create  empty  database: 

CREATE  TABLE  portalusers  ( 

user  id  CHAR(32)  PRIMARY  KEY, 
user  name  VARCHAR(IOO)  UNIQUE, 
pswd  hash  CHAR(32), 

role  ENUM  ("GroupLeader",  "GroupMember"), 
rcv_pub_alerts  BOOLEAN 
); 


CREATE  TABLE  missions  ( 

missionnum  VARCHAR(IO)  PRIMARY  KEY, 
description  TEXT, 

Duration  INT, 

Location  VARCHAR(IOO) 

); 


CREATE  TABLE  groups  ( 

groupid  INT  PRIMARY  KEY  AUTO  INCREMENT, 
group  name  VARCHAR(IOO), 
missionnum  VARCHAR(IO), 

CONSTRAINT  groups  msn  num  fk  FOREIGN  KEY  (mission  num) 

REFERENCES  missions(mission  num)  ON  DELETE  SET  NULL 
ON  UPDATE  CASCADE 

); 

CREATE  TABLE  belongsto  ( 

user  id  CHAR(32)  NOT  NULL, 
group  id  INT, 

CONSTRAINT  bel_to_user_id_grp_id_pk  PRIMARY  KEY  (user  id,  group  id), 
CONSTRAINT  bel_to_user_id_fk  FOREIGN  KEY  (user  id) 

REFERENCES  portalusers  (user  id)  ON  DELETE  CASCADE 
ON  UPDATE  CASCADE, 

CONSTRAINT  beljo  grp  id  fk  FOREIGN  KEY  (group  id) 

REFERENCES  groups  (group  id)  ON  DELETE  CASCADE 
ON  UPDATE  CASCADE 

); 
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CREATE  TABLE  devices  ( 

deviceid  INT  PRIMARY  KEY  AUTO  INCREMENT, 
ipaddr  VARCHAR(IOO)  DEFAULT  'Temp Value', 
macaddr  VARCHAR(IOO)  DEFAULT  '  Temp  Value', 
battjevel  INT  DEFAULT  0, 

device  sn  VARCHAR(30)  UNIQUE  DEFAULT  '  TempValue' 

); 


CREATE  TABLE  uses  ( 

user  id  CHAR(32)  PRIMARY  KEY, 
device  id  INT, 
time_sig_in  TIMESTAMP, 

CONSTRAINT  uses  user  id  fk  FOREIGN  KEY  (user  id) 

REFERENCES  portalusers(user  id)  ON  DELETE  CASCADE 
ON  UPDATE  CASCADE, 

CONSTRAINT  uses_device_id_fk  FOREIGN  KEY  (device_id) 

REFERENCES  devices(device  id)  ON  DELETE  NO  ACTION 
ON  UPDATE  CASCADE 

); 


CREATE  TABLE  specialtags( 

tagnum  INT  PRIMARY  KEY  AUTO  INCREMENT, 

gender  VARCHAR(IOO), 

age  VARCHAR(IOO), 

lastname  VARCHAR(IOO), 

first  name  VARCHAR(IOO) 

); 


CREATE  TABLE  contentinfo( 

content_id  INT  PRIMARY  KEY  AUTO  INCREMENT, 

filename  VARCHAR(  100), 

file  size  VARCHAR(IOO), 

file  type  VARCHAR(IO), 

public_yn  BOOLEAN, 

cached  BOOLEAN  DEFAULT  false, 

date_created  DATETIME, 

dateshared  DATETIME, 

lastrequest  DATETIME, 

tag  num  INT  NOT  NULL, 

user  id  CHAR(32)  NOT  NULL, 

CONSTRAINT  contentinfo  tag  num  fk  FOREIGN  KEY  (tag  num) 
REFERENCES  specialtags(tag  num)  ON  DELETE  CASCADE 
ON  UPDATE  CASCADE, 

CONSTRAINT  contentinfo  user  id  fk  FOREIGN  KEY  (user  id) 
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REFERENCES  portalusers(userid)  ON  DELETE  CASCADE 
ON  UPDATE  CASCADE 


Script  to  create  initial  database  information: 

INSERT 

INTO  specialtags  (gender,  age,  last  name,  first_name) 

VALUES  ('None  supplied',  'None  supplied',  'None  supplied',  'None  supplied') 
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